The present invention is related to computer-system security, in particular, to the process by which a secure computing platform is bootstrapped during initialization or restart of a secure computing platform, including secure firmware and optionally including a secure kernel. The techniques of the present invention are, however, potentially applicable to many other secure-computing problems.
FIGS. 1A-C illustrate a secure-computing-platform booting problem described below as an example of the application of one embodiment of the present invention. FIG. 1A shows a number of components of a computer system, including: (1) a processor 102; (2) a read-only memory (“ROM”) 104, soldered into the system for security reasons, discussed below, that stores the first instructions/routine 106 executed by the processor following a hard reset or boot; (3) two flash memories 108 and 110 that contain a number of firmware modules 112-117 that are run during system bootstrap, and some of which that are subsequently called as library routines through various interfaces by an operating system; (4) a system bus 120; (5) a bus bridge 122 interconnecting the system bus 120 with a peripherals bus 124; (6) an I/O controller 126 that controls a mass-storage device 128, such as a disk drive; and a system memory 130. As shown in FIG. 1A by arrow 132, following a hard reset or power on, the processor 102 is hardwired to fetch initial instructions, or, equivalently, an initial routine or set of routines 106, from the ROM memory 104. Because a secure system is to be bootstrapped, the initial routine or set of routines needs to be verifiably secure. Thus, the computer-system manufacturer creates the initial routine or routines and verifies their security, and places them on a true ROM that cannot be overwritten and can only be replaced by physically removing the ROM from the computer system. Once the initial routine or routines are executed, the computer system proceeds to successively access and execute firmware modules 112-115 incorporated into one of the flash memories 108, as shown in FIG. 1B. Then, as shown in FIG. 1C, additional firmware modules 116 and 117 in another flash memory 110 are accessed and executed. Eventually, one or intermediate phases are reached, after which an operating system kernel can be loaded from the mass-storage device 128 into memory and the operating system can be securely booted to produce a fully functional, secure computer system.
The bootstrap discussed above with reference to FIGS. 1A-C begins securely, with routines extracted from a true ROM memory, but when the first firmware module in flash memory is accessed, security mechanisms must be in place to validate the security of the firmware module. Flash memories may be rewritten, and can thus be maliciously altered after the computer system has been shipped from the manufacturer. While the ROM can be depended on to be secure, the first routines executed from the ROM must validate the first firmware module accessed, and each firmware module successively accessed must be verified. This verification cannot depend on retrieving information from outside of the computer system, and may not even be able to access information stored on mass-storage devices or on other peripheral devices.
Various techniques have been developed for facilitating a secure boot process, a portion of one example of which is illustrated in FIGS. 1A-C. There are various integrated circuits devoted specifically to security purposes, such as the Trusted Computing Platform Alliance (“TCPA”) trusted platform module (“TPM”). Certain modern computer architectures provide simple machine checking of a portion of an initial firmware image. In addition, various rather elegant cryptography-based methodologies have been proposed for general authentication and validation of software executables. However, each of these types of techniques and methodologies for addressing the secure-boot problem have attendant disadvantages and deficiencies. The TCPA TPM chip may require expensive engineering to be incorporated into a secure computing environment. The simple machine checking cannot be performed to validate and authenticate third-party firmware images loaded during a secure boot. Many of the elegant cryptography solutions require storage of cryptographic keys in ways that create vulnerabilities at the hardware level. For these reasons, designers, manufacturers and users of computing systems have recognized the need for a relatively inexpensive, secure, and reliable method for authenticating and validating firmware modules during sequential loading up and building of a secure kernel or monitor via a secure bootstrap process.